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Prin modelarea conceptuală a datelor se urmăreşte construirea unui model al datelor care să 
asigure transpunerea exactă a realității din domeniul analizat, fără a lua în considerare cerințele 
specifice unui model de organizare a datelor (cum este modelul relațional), criteriile de calitate privind 
organizarea datelor, cerinţele nefuncționale ale sistemului şi criteriile de performanţă privind stocarea 
şi accesarea datelor. În acest sens, se construieşte diagrama entitate-relaţie, care evidenţiază entităţile 
de date din sistem, atributele acestora, precum şi legăturile dintre entități. Modul în care vor fi 
implementate legăturile dintre entități, de exemplu, nu interesează în acest moment, atenţia fiind 
îndreptată doar spre identificarea şi descrierea lor. 


6.1 Rolul modelării datelor 


Introducerea modelului entitate-relație (ER) a apărut ca răspuns la complexitatea proiectării 
logice a bazelor de date de dimensiuni mari. Argumentarea acestei modalități de abordare a datelor 
constă în faptul că în proiectarea tradițională a bazelor de date, în special a celor relaționale, 
presupune constituirea relaţiei universale prin reunirea tuturor datelor elementare (atribute) 
identificate în faza de analiză şi repartizarea lor în tabele pe baza analizei dependențelor dintre 
atribute (dependențe funcționale, dependențe multivaloare şi de joncțiune) şi aplicarea procesului 
de normalizare. Abordarea se pretează foarte bine în cazul bazelor de date de dimensiuni mici şi 
medii, dar devine destul de greoaie în cazul bazelor de date de dimensiuni mari şi foarte mari. 

Modelarea conceptuală a datelor cu ajutorul diagramelor entitate-relație (DER) a fost descrisă 
prima dată în lucrările lui P.P. Chen, publicate în 1976, deşi primele încercări de formalizare sunt 
înregistrate în anii '60 şi aparţin lui Charles Bachman. Ulterior, modelul lui Chen a înregistrat 
numeroase modificări şi extensii. Simplitatea, uşurinţa învățării şi posibilitatea formalizării 
cerințelor sistemului aşa cum sunt ele în realitate, independent de opţiunile de organizare şi 
tehnologice au sporit vertiginos popularitatea modelului ER încă din anii '80. 

Noua abordare presupune, mai întâi, modelarea conceptuală a datelor prin construirea 
diagramei entitate-relație (DER), care evidențiază entitaţile de date ale sistemului, proprietățile 
acestora şi legăturile dintre entități. Ulterior, prin aplicarea unor reguli simple, are loc 
transformarea modelului entitate-relaţie în schema logică a bazei de date. Tabelele astfel obținute 
sunt, în final, analizate din perspectiva normalizării putând rezulta noi tabele. 

Utilizarea modelului ER oferă o serie de avantaje faţa de abordarea tradiţională”: 

e reprezintă un util instrument de comunicare între echipa de dezvoltare a sistemului 
(analişti şi proiectanți) şi utilizatorii finali pe parcursul fazelor de analiză şi proiectare 
conceptuală şi logică; 

e este uşor de înțeles şi conceput. Ca şi în cazul modelării proceselor, prezentarea grafică 
permite exprimarea unui volum mare de informaţii sub o formă compactă, uşor de urmărit 
şi înţeles; 

e apelează la abstractizare, ceea ce reduce considerabil numărul obiectelor luate în 
considerare la analiza şi proiectarea bazei de date. Prin utilizarea noțiunii de entitate ca 
abstractizare pentru datele elementare (atribute) se vor analiza mai puţine obiecte (numărul 
entitaților de date este mult mai mic decât numărul datelor elementare din sistem) şi mai 
puţine relaţii între obiecte (numărul relaţiilor dintre entități este mult mai mic decât 
numărul relațiilor de dependență existente între atribute). Deşi datele elementare sunt 
reprezentate şi în această abordare, ca proprietăți ale entităților, numărul dependenţelor ce 
trebuie analizate este mult redus, fiind luate în considerare doar cele stabilte la nivelul 
entităților şi nu la nivelul tuturor atributelor din relația universală pe baza căreia se 
construieşte baza de date; 

e existența unui set complet de reguli de transformare a DER în tabele ale bazei de date. 
Aceste reguli permit transformarea simplă şi rapidă a cerințelor informaţionale ale 


2 adaptare după Teorey, T.J., Database Modeling & Design, Morgan Kaufmann Publishers, Inc, 1999, p.46 
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sistemului, structurate în DER, în baza de date. Majoritatea instrumentelor CASE oferă 
suport pentru generarea automată a bazei de date în funcţie de SGBD-ul dorit. 


6.2 Definirea conceptelor utilizate în construirea DER 


Analiza cerinţelor informaţionale ale noului sistem reprezintă etapa cea mai importantă care stă 
la baza proiectării bazei de date. Înglobarea acestor cerințe în schema finală a bazei de date 
reprezintă o provocare pentru proiectanți. Obiectivele majore ale analizei cerințelor din perspectiva 
modelării datelor vizează“: 

e descrierea cerinţelor de date ale sistemului în termenii entităților de date; 

e colectarea informaţiilor care descriu entitățile de date şi relațiile dintre acestea care să 

permită construirea DER; 

e determinarea tranzacţiilor ce vor fi efectuate asupra bazei de date şi descrierea interacțiunii 

dintre tranzacții şi entitățile de date; 

e definirea cerințelor nefuncționale ale bazei de date, cum ar fi cele legate de performanțe, 

integritate, securitate, administrarea datelor; 

e specificarea platformei hardware şi software pe care va fi implementată baza de date. 

După formularea clară a cerinţelor se trece la formalizarea acestora, respectiv construirea DER, 
care are la bază trei clase de obiecte: entităţi, atribute şi relaţii, şi presupune parcurgerea a doi paşi: 

e identificarea şi descrierea entităților şi 

e definirea relaţiilor dintre entități. 


6.2.1 Identificarea şi descrierea entităţilor de date 


Prin entități de date se face referire la obiectele despre care este nevoie să se memoreze 
informații. De regulă, ele se referă la locuri, persoane, lucruri, evenimente în legătură cu care există 
interes din perspectiva stocării datelor. Un caz particular al unei entități este numit instanță sau 
ocurență. Astfel, o entitate va conţine mai multe instanţe de acelaşi tip, adică instanţe cu proprietăți 
comune. Unii autori utilizează noțiunile de clasă de entităţi şi entitate pentru entitate şi, respectiv, 
instanță. 

Exemple de entități sunt: angajat, care va avea drept instanțe toți angajaţii dintr-o firmă; 
furnizor, care va conţine toți partenerii de afaceri cu care firma are relații de aprovizionare; 
consum, care va avea drept instanţe toate documentele de consum înregistrate într-o perioadă de 
timp în firmă. Alte exemple pot fi: departament, produs, student, disciplina, profesor, localitate etc. 

O entitate este descrisă prin intermediul atributelor. Atributele reprezintă proprietăți ale 
entității pe care o descriu, toate instanțele unei entități fiind descrise de aceleaşi atribute. Un atribut 
al unei instanţe dintr-o entitate se numeşte valoarea atributului. De exemplu, atributele care 
caracterizează entitatea angajat pot fi: marca, numele, adresa, numărul de telefon, CNP, funcţia, 
salariul etc. 

Există două tipuri de atribute: identificatori şi descriptori. Un identificator (numit şi cheie) are 
rolul de a identifica în mod unic fiecare instanță care poate popula o entitate de date. În schimb, 
descriptorii specifică caracteristici ne-unice ale instanţelor unei entități. 

Depistarea entităţilor unui sistem nu reprezintă o activitate tocmai uşoară. În multe situaţii 
analistul trebuie să decidă dacă un obiect reprezintă o entitate, un atribut al unei entităţi sau o 
relație între entităţi. Să luăm drept exemplu obiectul localitate, el reprezintă o entitate sau un 
atribut? În sistemul de aprovizionare, el ar putea reprezenta o entitate sau doar atributul entității 
furnizor. Un alt exemplu este comanda; reprezintă comanda o entitate sau o relaţie între entitățile 
Material şi Furnizor? 

La clasificarea entităților şi atributelor trebuie respectate următoarele două reguli: 


3 Teorey, T.J., Database Modeling & Design, Morgan Kaufmann Publishers, Inc, 1999, p.46-47 
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e entitățile trebuie să conţină informaţii descriptive. Conform acestei reguli, dacă pentru un 
obiect există informaţii descriptive (adică mai multe atribute care să o caracterizeze) atunci 
acel obiect constituie o entitate. Altfel, dacă pentru obiectul respectiv este necesar doar un 
identificator, nefiind solicitate atribute de tip descriptori, atunci acel obiect va reprezenta un 
atribut. Dacă pentru obiectul Localitate sunt necesare mai multe informaţii descriptive (cum 
ar fi județul, regiunea, numărul populaţiei etc.) atunci el trebuie clasificat ca entitate. Dacă 
se solicită doar numele localităţii, atunci el va fi doar un atribut al unei entități (cum ar fi 
furnizor, angajat, departament etc.). 

e un atribut trebuie ataşat acelei entităţi pe care o descrie în modul cel mai direct. De regulă, 
o proprietate se referă la o singură entitate, deci un atribut va fi regăsit doar la o singură 
entitate. În sistemul de aprovizionare, de exemplu, entitatea Comandă nu va conţine nici 
numele furnizorului (sau codul acestuia), nici denumirea materialului (sau codul 
materialului); aceste atribute caracterizează mai direct entitățile Furnizor şi, respectiv, 
Material. Nu intră sub incidenţa acestei reguli sinonimele. Un exemplu în acest sens poate 
fi atributul adresa: el poate caracteriza atât entitatea angajat, cât şi entitatea furnizor. 

Aşadar, clasificarea unui obiect ca entitate sau atribut presupune analiza cu multă atenţie a 

documentaţiei sistemului în care sunt formulate şi detaliate cerințele informaţionale. 


6.2.2 Definirea relaţiilor dintre entităţile de date 


O relaţie reprezintă legătura care există în lumea reală între una, două sau mai multe entități. 
Relaţiile nu au o existență fizică sau conceptuală, ci depind de entitățile asociate. Altfel spus, 
existenţa relațiilor depinde de existența entităților asociate (în schimb existența unei entități nu 
depinde de existenţa unei relaţii cu o altă entitate). Un caz particular al unei relații se mai numeşte 
instanța relaţiei sau ocurenţa relaţiei. Instanţa relaţiei se referă la legătura dintre instanțele 
entităților asociate. Exemple de relaţii sunt: emite, între entitățile Factura şi Furnizor; conține, între 
entitățile Factura şi Produs; este condus, între entităţile Departament şi Angajat sau orice verb care 
care descrie conexiunea dintre entități. 

Descrierea unei relaţii presupune specificarea următoarelor elemente: ordinul (gradul), 
cardinalitatea, rolul şi eventualele atribute care o caracterizează. În continuare ne vom opri pe rând 
asupra fiecărui element descriptiv. 

Ordinul relației este dat de numărul entităților asociate printr-o relaţie. Conform acestui 
criteriu, relațiile pot fi clasificate în: 

e relații recursive, numite şi relaţii ale entității cu ea însăşi. Acest tip de relație leagă două 

instanţe ale aceleiaşi entități. Un exemplu de relație recursivă este redat în figura 6.1. 


Angajat 

Ang id Un angajat poate fi căsătorit 

Ang_nume cu un alt angajat din aceeaşi 
firmă, dar nu este obligatoriu. 


Este 
căsătorit 
cu 


Fig. 6.1 Relaţie recursivă 


e relații binare, în care sunt implicate două entităţi. Acest tip de relaţii sunt de departe cele 
mai întâlnite în lumea reală. Mai mult, unele metode utilizează doar acest tip de relații la 
construirea modelului ER. Exemple de relaţii binare se regăsesc în următoarea figură: 
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Furnizor 
Furn_id 
Furn_nume O factură este emisă de un 
(1,1) furnizor, în timp ce un furnizor 
poate emite mai multe facturi 
sau nici una. 
(0.M) 
Factura 
Fact_id 
Fact data 


a) Exemplu 1 de relație binară 


Fiecare factură are în corespondență 
doar o recepţie şi numai una, iar o 
recepţie are la bază exact o factură. 


Fact_id 
Fact_nr 
Fact_data 


Receptie 
Rec_id 
Rec_nr 
Rec_data 


b) Exemplu 2 de relație binară 
Fig. 6.2 Relaţii binare 


relaţii de ordinul n, numite şi relaţii n-are. Acest tip de relații se stabileşte între trei sau 
mai multe entități. Dacă numărul entităţilor implicate într-o relaţie este 3, atunci vom avea 
o relaţie ternară. Astfel de exemple sunt prezentate în figura 6.3. Relațiile ternare sunt mai 
rar întâlnite în lumea reală, ele fiind utilizate atunci când nu este suficientă utilizarea 
relaţiilor binare pentru descrierea cu acuratețe a semanticii relației respective. 


Tehnician 
Ang_id 
Ang_nume 
1 
Proiect 1 1 Documentatie 
Pr_id Doc _nr 
Pr_den Doc_termen 


Un tehnician poate lucra la mai multe proiecte, însă el intocmeşte o singură documentație 
pentru fiecare proiect în parte; fiecare documentaţie este întocmită de un singur tehnician 
pentru un singur proiect; un proiect poate avea mai multe documentații, dar fiecare 
documentaţie va fi intocmită de un singur tehnician. 


a) Exemplu 1 de relaţie ternară 
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Ang_id 
Ang_nume 


Formatie 
Form_id 
Form_nrang 


Loc_munca 
Locm_id 
Locm den 


Fiecare angajat poate lucra in mai multe locuri de munca in formatii de lucru 
diferite, o formatie este formata din mai multi angajati si poate lucra in mai 
multe locuri de munca, iar intr-un loc de munca pot lucra mai multe formatii 
alcatuite din mai multi angajati. 


b) Exemplu 2 de relație ternară 


Fig. 6.3 Relații ternare 


6.2.3 Cardinalitatea relațiilor 


Următorul element utilizat pentru descrierea relațiilor îl reprezintă cardinalitatea. 
Cardinalitatea unei relații defineşte numărul instanțelor unei entități care pot fi asociate unei 
instanțe a celeilalte entități prin intermediul relației considerate. Pentru o relație dată trebuie 
specificată cardinalitatea pentru fiecare entitate asociată. Cardinalitatea relației pentru o entitate 
este sugerată printr-o pereche de valori, în cazul relațiilor binare trebuind specificate două astfel de 
perechi de valori. Valorile care compun o astfel de pereche semnifică: 

e cardinalitatea minimă, pentru care sunt posibile valorile „0” sau „1”, şi 

e cardinalitatea maximă, pentru care sunt posibile valorile ,„1” sau „M” (adică „multe”). 

Să luăm drept exemplu relaţia emite/este emis dintre entităţile Furnizor şi Factura, prezentată 
în figura 6.4. Cardinalitatea minimă a relaţiei pentru entitatea Factura este „1”, iar cea maximă este 
tot „1”; cardinalitatea relației pentru entitatea Furnizor este „0”, respectiv „M”. Prin urmare, în 
relația emite/este emis, unui furnizor (care este o instanţă a entității Furnizor) îi poate corespunde 
minim O şi maxim „multe” facturi (adică instanţe ale entității Factura), în timp ce unei facturi îi 
corespunde minim un furnizor şi maxim tot un furnizor. Dacă luăm în considerare şi numele relaţiei 
(sau rolurile entităților în cadrul relaţiei), atunci o relaţie poate fi citită în ambele sensuri astfel: 

„un furnizor emite 0 sau mai multe facturi”, respectiv 
„O factură este emisă de un furnizor şi numai unul”. 


Fig. 6.4 Cardinalitatea relaţiilor 


Anterior am prezentat clasificarea relaţiilor în funcție de gradul lor. Un alt criteriu de 
clasificare a relațiilor este legat de cardinalitatea maximă. Astfel, în cazul relațiilor recursive şi al 
celor binare vom avea trei tipuri de relaţii: 

e relații de tipul 1:1 (unu-la-unu), adică o instanţă a entității X este asociată unei singure 

instanţe a entității Y şi reciproc. Exemple se regăsesc în figurile 6.2 b), dar şi în figura 6.5. 
e relații de tipul I:N (unu-la-multe), însemnând că o instanţă a entității X poate fi asociată la 
n instanţe ale entității Y, în timp ce o instanţă a entității Y va fi asociată doar unei singure 
instanţe a entității X. Acest tip de relaţii este cel mai des întâlnit în lumea reală, exemple 
fiind prezentate în figura 6.2 a), dar şi în figura 6.6. 

e relații de tipul M:N (multe-la-multe), care presupun că orice instanţă a entității X poate fi 
asociată mai multor instanţe ale entității Y, iar o instanţă a entității Y poate de asemenea să 
aibă asociate mai multe instanţe ale entității X (figura 6.7). 
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Departament Fiecare departament trebuie să aibă 
un manager, iar un angajat poate fi 
managerul unui singur departament 
dar nu este obligatoriu ca fiecare 

angajat să conducă un departament 


Angajat 
Ang_id 
Ang_nume 
Ang_saltf 


Fig. 6.5 Exemplu de relaţie 1:1 


Departament Fiecare departament publică unul 
sau mai multe rapoarte, însă nu 
este obligatoriu ca un raport să fie 
publicat de un anumit 
departament. 


Fig. 6.6 Exemplu de relație 1:N 


Produs 
Prod_id 
Prod_den Fiecare factură poate conţine mai 
multe produse, iar un produs se 
(I.M) poate regăsi pe mai multe facturi. 
(0,M) 
T 
Factura 
Fact_nr 
Fact _data 


Fig. 6.7 Exemplu de relație M:N 


Generalizând, se poate afirma că o relație de ordinul n va înregistra n+1 tipuri de relații din 
punctul de vedere al cardinalității maxime. Dacă, după cum deja am văzut, în cazul unei relații de 
ordinul 2 avem 3 tipuri de relații, pentru o relație de ordinul 3 (relație ternară) vom avea 3+1=4 
tipuri de relații: 1:1:1 (fig. 6.3 a)), 1:1:P, 1:N:P (fig. 6.8) şi M:N:P (fig. 6.3. b)). 

S-a discutat până acum importanța cardinalității maxime, însă şi cardinalitatea minimă are o 
semnificaţie importantă în proiectarea bazelor de date, ea fiind legată de conceptul de restricție de 
dependență”. Dacă existenţa instanţei x din entitatea X depinde de existenţa instanţei y din entitatea 
Y, se spune că x este dependentă de y; de aici rezultă că ştergerea entității y atrage automat 
ştergerea entității x din baza de date. Se spune că existenţa instanţei x depinde de existenţa instanţei 
y. Entitatea Y este denumită entitate dominantă, iar entitatea X este denumită entitate dependentă. 


4 Korth, H.F., Silberschatz, A., Sistemes de gestion de bases de donees, McGraw-Hill, Paris, 1988, citat în Fotache, M., Baze de date 
relaționale. Organizare şi interogare, Ed. Junimea, laşi, 1996, p. 69 
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Profesor 
Prof_id 
Prof nume 
1 
Disciplina N Student 
Disc_id Examinează Stud_id 
Disc_den Stud_nume 


Fiecare student susține un examen cu un singur profesor, însă el poate fi 
examinat de acelaşi profesor la mai multe discipline. De asemenea, un profesor 
examinează la o disciplină mai mulţi studenți. 


Fig. 6.8 Exemplu de relaţie 1:N:P 


Revenind la exemplul anterior cu relaţia emite/este emisa, entitatea Factura este dependentă de 
entitatea Furnizor, deci Furnizor este o entitate dominantă. Ştergerea unei facturi nu atrage automat 
şi ştergerea furnizorului care a emis-o, deoarece este posibil ca în baza de date să mai rămână 
facturi primite de la furnizorul respectiv. În schimb, ştergerea unui furnizor atrage după sine 
ştergerea tuturor facturilor aferente acestuia. 

Relaţiile dintre entități pot fi clasificate după cardinalitatea minimă în două tipuri: relații 
facultative şi relaţii obligatorii. Altfel spus, participarea unei entităţi într-o relație poate fi 
facultativă sau obligatorie; participarea opțională este pusă în evidență prin cardinalitatea minimă 
„0” pentru o entitate, iar cardinalitatea minimă „1” semnifică faptul că acea entitate este obligatoriu 
să participe într-o relație. Se observă că în relaţia emite/este emisă entitatea Factura are 
cardinalitatea minimă ,„1l”, deci este obligatorie participarea oricărei instanţe (facturi) într-o relaţie, 
în timp ce cardinalitatea minimă pentru entitatea Furnizor este „0, ceea ce înseamnă că nu este 
obligatorie participarea fiecărui furnizor în relaţia emite/este emisă (va putea exista un furnizor care 
să nu participe în nici o relație). 

Rolul defineşte funcția care atrage entitatea într-o relaţie. Pentru o relație trebuie specificat 
rolul fiecărei entități asociate. De exemplu, în relația dintre Factura şi Furnizor exemplificată în 
figura 6., rolul entității Furnizor este Emite, iar cel al entității Factura este este emisă. Specificarea 
rolurilor jucate de entități în DER ajută la clarificarea aspectelor semantice ale modelării datelor, 
precum şi la citirea relaţiilor, după cum s-a văzut anterior. Prin combinarea rolurilor jucate de 
entitățile asociate se obține numele relaţiei (emite/este emisă). Totuşi, unele metode de recomandă 
utilizarea unui singur nume pentru o relaţie, stabilit prin alegerea unui substantiv care să reflecte 
logica legăturii dintre entitățile respective. De exemplu, pentru relația din figura 6.4 se poate utiliza 
numele Cumpărare sau Emitere. În această variantă, rolul fiecărei entităţi nu mai este specificat în 
mod explicit, însă el rezultă implicit din numele atribuit relaţiei. În lipsa unui substantiv 
semnificativ pentru logica relaţiei se poate alege un nume format din inițialele entităților asociate. 

Descrierea relaţiilor impune şi specificarea atributelor asociate, dacă ele există. De exemplu, 
relația Examen dintre entitățile Student şi Disciplină are ca atribute proprii Data _exam şi Nota. 
Întradevăr, atributul Nota reprezintă o proprietate relaţiei dintre un student şi o disciplină la care 
susține examen, adică o proprietate a relației stabilite între două instanţe ale celor două entități. 
Dacă Nota ar fi atribuită uneia din cele două entități, atunci am avea un atribut multivaloare, 
deoarece un student poate avea mai multe note (pentru fiecare disciplină la care a susținut examen), 
iar la o disciplină ar putea exista mai multe note (pentru fiecare student care a susţinut examen la 
disciplina respectivă). Modul de repezentare grafică a atributelor asociate relaţiilor este prezentat în 
figura 6.9. Dacă unele notații nu utilizează un simbol special pentru relaţii (aşa cum este rombul în 
figura 6.9) atunci se va introduce în diagramă o entitate asociativă care, pentru moment, nu va avea 
cheie primară. 

Relaţii purtătoare de atribute sunt întâlnite doar în cazul relațiilor binare de tipul „multe-la- 
multe” sau a relaţiilor ternare. Relaţiile binare de tipul „unu-la-unu” sau „unu-la-multe” nu pot avea 
atribute, deoarece cel puţin una dintre entitățile asociate prezintă cardinalitatea maximă „unu”, ceea 
ce înseamnă că eventualele atribute ale relației vor putea fi ataşate unei entități fără ambiguitate. 


Cap. 6-8 


MODELAREA CONCEPTUALĂ A DATELOR: DIAGRAMA ENTITATE-RELAȚIE 


Prof_id 
Prof_nume 


Disc_id Stud_id 
Disc den Stud nume 


Data_exam Nota_exam 


Fig. 6.9 Exemplu de relaţie purtătoare de atribute 


Aplicarea tuturor conceptelor prezentate anterior permit descrierea suficient de clară a tuturor 
relațiilor între entități identificate în domeniul problemei analizate. O atenţie deosebită trebuie 
acordată relaţiilor redundante. Două sau mai multe relații sunt considerate redundante atunci când 
ele sunt utilizate pentru a reprezenta acelaşi concept. Un exemplu de relație redundantă este cea 
dintre Furnizor şi Plata din figura 6.10. Relaţia dintre Furnizor şi Plata este mai curând una 
indirectă, deoarece se urmăreşte plata facturilor primite. Dacă s-ar ţine o evidență globală a 
datoriilor către furnizori, atunci ar trebui eliminată relația dintre Factura şi Plata. Indiferent de 
tipul de evidenţă, una din cele două relaţii trebuie eliminată. 


1,1 


Fig. 6.10 Exemplu de relație redundantă 


In schimb, în figura 6.11 nici una dintre cele trei relații nu este redundantă atât timp cât 
membrii unei asociații pot locui în altă localitate decât cea în care îşi are sediul asociația. Dacă ar 
exista restricția ca toți membrii unei asociații să locuiască în localitatea de reşedinţă a asociației, 


atunci relația dintre Membru şi Localitate ar fi redundantă. 


0,M 
Locuieşte 


(1,M) (1,1) 


Asociaţie 


Fig. 6.11 Exemplu de relaţii neredundante 


Aparține 


Este localizată 


6.2.4 Construirea diagramelor entitate-relaţie 


Pentru construirea DER se apelează la simbolul dreptunghi, pentru fiecare entitate. Se 
recomandă ca numele entității să fie redat printr-un substantiv la singular (CLIENT, PRODUS, 
SALARIAT etc.). 

După ce se identifică entităţile, se continuă cu împerecherea lor, fiecare cu fiecare, pentru a 
descrie ce relaţii există între ele. 

De exemplu, pentru a arăta că o anumită vânzare se referă doar la un client, deşi sunt mult mai 
multe acte de vânzare, implicit mai mulţi clienţi, relaţia poate fi redată schematic astfel: 


CLIENT VANZARE 


O vânzare, la rândul ei, constă din unul sau mai multe produse, dar şi produsele pot constitui 
subiecte ale mai multor vânzări, deci între entitățile VANZARE şi PRODUS se va folosi câte o 
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săgeată la fiecare capăt al liniei ce leagă cele două entități. Continuăm cu descrierea 
legăturilor/relaţiilor posibile: un PRODUS este în legătură directă doar cu o singură înregistrare 
STOC, şi invers; ca atare, ele vor fi marcate printr-o linie simplă. Antrenând în sfera discuţiilor şi 
comanda de aprovizionare, COMANDA, şi furnizorul, FURNIZOR, s-ar putea construi diagrama 


entitate-relaţie din fig. 6.12. 
PRODUS | soc | | FURNIZOR | 


CLIENT 
CEA 


CEA 
Fig. 6.12 Diagrama entitate-relație pentru operațiunea de vânzare-cumpărare 


În lucrul cu DER, de o mare importanţă, în activitatea de analiză a acestora, este cunoaşterea 
faptului că întotdeauna relațiile multe-la-multe pot fi descompuse în două relaţii de tipul unu-la- 
multe, prin aflarea entităţii-intersecție. Diagrama dintre PRODUS şi VANZARE, de tip multe-la- 
multe, în forma ei inițială, poate fi redată astfel: 


PRODUS VANZARE 


Descompunerea ei în două relaţii de tipul unu-la-multe poate fi redată sub forma: 


PRODUS VANZARE 


PRODUS — VANZARE 


Entitatea-intersecție este ceva ce se va impune de la sine între cele două entități, putându-se 


marca momentul de căutare a noii entități astfel: 
77? — VANZARE 


Semnele de întrebare înseamnă ce răspuns trebuie să ne găsim la întrebările: Ce ar putea fi 
asociat cu entitatea generală simplă PRODUS care să poată da naştere la o legătură de tip 
multe?, precum şi Ce anume s-ar putea asocia entității simple VANZARE, printr-o legătură de tip 
multe, dar care să exprime relația dintre produse şi vânzări?”. 

Răspunsul este uşor de dat dacă s-ar folosi un substantiv la plural pentru una din cele două 
entități cunoscute, deşi normele nu o recomandă. Deci, ce s-ar interpune între o relație de forma 
PRODUSE-VANZARE? Răspunsul este clar: un articol anume, deoarece vânzarea constă din mai 
multe articole vândute prin aceeaşi tranzacție externă. Schematic, diagrama va fi: 


PRODUS 


PRODUS TICOL_VANDU VANZARE 


La fel se poate proceda cu relația multe-la-multe dintre PRODUS şi FURNIZOR, 
descoperindu-se o nouă entitate, SURSA PRODUS, care exprimă faptul că un furnizor poate fi 
sursa de livrare pentru orice produs, la un preţ dat şi la un anumit moment contractual. 

Relaţiile unu-la-unu, de asemenea, sunt supuse analizei pentru a putea constata dacă într- 
adevăr cele două entităţi simple sunt total diferite şi nu pot fi combinate în nici un mod. În 
exemplul anterior, există doar o singură relație unu-la-unu, cea dintre PRODUS şi STOC. Dacă 
entitatea PRODUS va prelua elementele din STOC, atunci cea de-a doua poate să dispară. Este 
cazul tipic al nomenclatoarelor, care pot prelua şi elemente ale unor fişiere de stare. 
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În urma analizelor efectuate asupra diagramei entitate-relaţie, din fig. 6.12, şi a modificărilor 
aduse, rezultă o nouă diagramă (fig. 6.13): 


CLIENT de 
(include si 
STOC) FURNIZOR 


COMANDA_ 
VANZARE ARa APROVIZIONARE 


Fig. 6.13 Noua DER pentru operațiunea de vânzare-cumpărare 


6.2.5 Notaţii folosite pentru construirea DER 


Notaţia Chen 


P.P.Chen este considerat creatorul modelului diagramei entitate-relație (DER), care acordă o 
importanţă deosebită relației ce se poate stabili între două entități, prin folosirea unui simbol 
special, rombul, pentru redarea acesteia, iar pentru tipul relației (1:1, 1:Multe, Multe:Multe) 
apelează la caracterele 1, M, N, plasate chiar pe liniile de legătură dintre entitate şi relație sau 
dintre relație şi entitate. Nu se utilizează vârfuri de săgeți, conform următoarelor exemple: 


COORDONATOR H C> f mou | 
FURNIZOR |M re> N| — propus 


Notaţia Ross 


Ca şi Chen, Ross foloseşte simbolul romb pentru a reprezenta relația sau asocierea, în schimb 
renunță la caracterele 1, M, N pentru redarea tipului acesteia, apelând la vârful de săgeată unic 
(pentru 1) sau dublu (pentru M). Exemplele anterioare devin: 


COORDONATOR. C> BIROU 
a j> 
VANZARE 


Un aspect nou îl reprezintă şi tratarea diferențiată a tipurilor de entități, Ross recunoscând ca 
tipuri: entităţile de fond (de bază), care sunt de sine stătătoare (CLIENT, ANGAJAT, PRODUS, 
CLADIRE ş.a.) şi entităţile-caracteristică, numite şi entităţi dependente, care nu pot exista fără 
o entitate de fond (ar fi cazul cont clienți, repartizări-pe-locuri-de-muncă ş.a.). Pentru a le 
diferenția, Ross foloseşte o notație specială: în colțul din stânga sus al entităţii-caracteristică 
delimitează o casetă mică în care plasează litera C: 
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ANGAJAT STUDII_IN_LUCRUJ 


Notaţia LBMS 


Combinația de litere provine de la numele furnizorului produsului CASE AUTOMATE-PLUS, 
acesta fiind Learmonth and Burchett Management Systems (LBMS). Autorii produsului folosesc 
doar relații de tipul unul-la-multe (1:M) în construcția DER, pe care ei le numesc Logical Data 
Structures (LDSs), structuri logice ale datelor. Ca atare, orice relație de tip multe-la-multe (M:N) 
este descompusă în relaţii unu-la-multe (1:M), apelând la entitatea intersecție. Edificator este 
exemplul: 


Notaţiile folosite sunt: 

e linia simplă, fără vârf de săgeată, înseamnă “1”; 

e linia finalizată cu un singur vârf de săgeată înseamnă “M” (multe); 

e relație opțională este marcată printr-un cerculeț plasat la mijlocul liniei ce uneşte două 
entități (—o—). 


Cap. 6-12 


